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5 FIELD OF THE INVENTION 

This invention relates to arrangements and methods for call establishment in voice 
over IP and voice over ATM networks. 

BACKGROUND TO THE INVENTION 

10 A recent development in the communications field has been the introduction of 
networks providing voice over IP (VoIP) and voice over ATM services. The 
advantage to users is the significant reduction in costs, particularly for calls set up 
over long distances which can often be billed at local call rates. In such networks, a 
PTT/AO network interfaces with a managed IP network via one or more media 

15 gateways, which gateways are managed by media gateway controllers. 

In the simplest architecture, a single media gateway controller (MGC) controls a 
number of media gateways (MG). This architecture, while valid for some call-types, 
will not become the predominant topology in voice over IP or voice over ATM 

20 networks, for a number of reasons. Firstly, a single media gateway controller will not 
have the capacity to control all media gateways in a large network. Secondly, for 
regulatory reasons in some countries, a media gateway controller will have to be 
located in the same country as those media gateways that it controls. Thirdly, 
service providers are now demanding vendor interoperability with media gateway 

25 controller from more than one vendor in their networks. Interoperability between 
service providers will be also required, with media gateway controllers and media 
gateways from more than one service provider communicating with each other. 

If this interoperability is to be achieved, then a number of key issues will first have to 
30 be addressed. Specifically, these are> 

a) Communication between Media Gateways from different vendors for the 
bearer path for VoIP and VoATM. 

b) Communication between a media gateway controller from one vendor and 
a media gateway from another vendor. 
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c) Communication between a media gateway controller from one vendor and 
a media gateway controller from another vendor. 

Currently, in the industry, the standards to achieve the first requirement (a) are 
5 pretty much in place. A codec (such as G.711), transported in RTP (rapid transport 
protocol), carried on UDP (user data protocol), on top of IP for VoIP is the currently 
recognized industry standard. 

An industry standard for the second requirement (b) is also nearing acceptance. 
10 While there are many device control protocols (SGCP, IPDC, MGCP, MEGACO, 
and, of course, some proprietary ones, vendor interoperability between media 
gateway controllers and media gateways is generally achievable. 

The third requirement (c) is however a much more difficult issue. A number of 

15 options have been tentatively proposed, but none of these has provided a 
satisfactory solution. One such proposal is the extension of ISUP to carry bearer 
information. This is referred to as ISUP+, or Q.BIC. Current proposals suggest the 
use of the CCS7 network for carriage of this information, but many service providers 
do not want to involve a CCS7 network in their Voice over Packet network design. 

20 Another proposed solution is that of changing the session initiation protocol SIP 
(RFC 2543) to allow carriage of both SDP (RFC 2327) and CCS7 user part 
information to allow PSTN interconnect and transparency, and using this information 
as the media gateway controller to media gateway controller (MGC to MGC) 
communication protocol. This is typically referred to as SIP BCP T (SIP Best 

25 Common Practices for Telephony). While this effort is currently under active 
consideration, a ratified, working protocol has yet to be defined. A third proposal is 
the use of a vendor specific protocol. While this is a working solution, it is a vendor 
specific one, and includes information specific to the vendor specific implementation 
of the ICE half-call split. This information will of course be proprietary and not 

30 generally available to other vendors. 

In addition to the protocol problem, a further difficulty is that the media gateway 
controllers developed by various vendors are designed to function in a network only 
if the other media gateway controllers in the network are derived from that vendor's 
35 same family of products. For example, a vendor's media gateway controller might 
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rely on sharing data across media gateway controllers such as translations, or trunk- 
groups, in order to function. Further, some vendors' media gateway controller 
products are designed such that one media gateway controller only deals with 
ingress half calls, and another media gateway controller deals with egress half calls. 
5 Intimate knowledge about how each media gateway controller works must be known 
by the other media gateway controller, and this of course generally precludes the 
use of products from another vendor. In addition, a media gateway controller will 
generally be designed to control both gateways. 

10 Thus, even if a ratified protocol were to be defined, this would not fully address the 
problem and, in the absence of a suitable topology, would be difficult to achieve in 
the near term: 

SUMMARY OF THE INVENTION 

15 An object of the invention is to minimise or to overcome the above disadvantage. 

A further object of the invention is to provide an improved arrangement and method 
for carrying narrow band traffic, e.g. voice traffic over an IP network. 

20 According to a first aspect of the invention, there is provided a communications 
network arrangement providing voice over IP or voice over ATM services, the 
network arrangement comprising: a first media gateway controller controlling a first 
gateway and provided with a first operating protocol, a second media gateway 
controller controlling a second gateway and provided with a second operating 

25 protocol, and a gateway address translator incorporating proxies for said first and 
second gateways respectively, wherein said gateway address translator provides a 
relay function for messaging between each said media gateway controller and its 
corresponding gateway, and a virtual bearer function for messaging between said 
media gateway controllers. 

30 

According to another aspect of the invention, there is provided a method of 
interfacing media gateway controllers and media gateways having different 
operating protocols in a communications network arrangement providing voice over 
IP or voice over ATM services, the method comprising creating software proxies of 
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said gateways with which said media gateways communicate each in its respective 
operating protocol. 

According to another aspect of the invention, there is provided a method of 
5 providing voice over IP or voice over ATM services in a communications network 
arrangement comprising: a first media gateway controller controlling a first gateway 
and provided with a first operating protocol, and a second media gateway controller 
controlling a second gateway and provided with a second operating protocol, the 
method comprising provisioning proxies of said gateways so as to provide a relay 
10 function for messaging between each said media gateway controller and its 
corresponding gateway, said messaging utilising the protocol of the controller and 
the gateway, and a virtual bearer function for enabling messaging between said 
media gateway controllers. 

15 According to another aspect of the invention, there is provided a gateway address 
translator for use in a communications network arrangement providing voice over IP 
or voice over ATM services and comprising: a first media gateway controller 
controlling a first gateway and provided with a first operating protocol,, a second 
media gateway controller controlling a second gateway and provided with a second 

20 operating protocol, the gateway address translator comprising; gateway proxies, one 
for each said gateway, and virtual gateways, one for each said media gateway 
controller, wherein said gateway proxies provide a relay function for messaging 
between each said media gateway controller and its corresponding gateway, and 
wherein said virtual gateways provide a virtual bearer function for messaging 

25 between said media gateway controllers. 

According to another aspect of the invention, there is provided a communications 
network arrangement providing voice over IP or voice over ATM services and 
incorporating a plurality of media gateways and media gateway controllers therefor 
30 whereby voice calls are set up over virtual channels in the network, wherein said 
media gateways and media gateway controllers have different operating protocols, 
and wherein communications between said media gateways and media gateway 
controllers are relayed via proxies whereby each said media gateway and media 
gateway controller can send and receive communications in its own protocol. 

35 
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Advantageously, the gateway address translator is provided on a storage medium 
as software in machine readable form. Preferably, this software is installed on and 
runs on a gateway controller. 

5 A media gateway controller may also comprise a soft switch or a USP/ICE - 
ICE/USP pair 

In some applications, communication between gateway controllers may be provided 
via a SS7 signalling network. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 

Embodiments of the invention will now be described with reference to the 
accompanying drawings in which:- 

15 Figure 1 is a schematic diagram of a prior art network arrangement; 

Figure 2 shows a development of the network of figure 1 ; 

Figure 3 shows a network construction according to a preferred embodiment of the 
20 invention; 

Figure 4 shows the detail of a gateway address translator employed in the network 
of figure 3; 

25 Figure 4a shows the gateway address translator construction in further detail; 
Figure 5 is a call walkthrough diagram for the network of figure 3; 
Figure 6 shows an alternative network construction; and 

30 

Figure 7 is a call walk-through diagram for the network of figure 6. 
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DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

Referring first to figure 1, which is introduced for explanatory and comparative 
purposes, this shows a typical network arrangement in which a single media 
5 gateway controller 11 controls first and second media gateways 12 and 13 so as to 
set up PTT network originating calls via a managed IP network 14. Communication 
between the media gateway controller and the gateways is established via a 
suitable device control protocol. Calls are set up via messages passed over e.g. a 
CCS7 signalling path 15 to the media gateway controller 11. 

10 

Figure 2, which is also introduced for explanatory and comparative purposes, shows 
a development of the network of figure 1 in which a further media gateway controller 
11a is introduced, e.g. to extend the geographical coverage of the network and/or to 
accommodate a larger number of gateways. The two media gateway controllers can 
15 communicate via the managed IP network 14 using a suitable inter-MGC 
communication protocol, and each can communicated with its respective gateway 
using a device control protocol. This however presupposes that both media 
gateway controllers use identical communication protocols and effectively requires 
that they be purchased from the same vendor. 

20 

Referring now to figure 3, this shows in schematic form an exemplary 
communications network arrangement according to a preferred embodiment of the 
invention. As shown in figure 3, the network arrangement includes a managed IP 
network, generally indicated as 34, to which access from one or more PTT/AO voice 

25 networks is provided via media gateways 32, 33. These gateways are supplied by 
different vendors and thus embody different operating protocols. Each gateway is 
controlled by a respective media gateway controller 31a, 31b whose protocols match 
those of the gateway that it is controlling. This control is effected using an 
appropriate device control protocol via a gateway address translator (GAT) 35. 

30 Communication between the media gateway controllers is also provided via the 
gateway address translator 35 which interfaces and converts the respective device 
control protocols used by the media gateway controllers. Each media gateway 
controller can thus use its own device control protocol for all communications via the 
gateway address translator. 

35 
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Signalling to provide setup of VoIP calls is advantageously effected via a CCS7 
network using an appropriate ISUP (ISDN user part) protocol for the particular 
administration in which the media gateway controllers are operating. The gateways 
provide user access to G.771/RTP traffic paths 36 via the IP network for the 
5 transport of voice over IP calls that have been set up via the CCS7 signalling 
network. 

It will of course be understood that, for the purposes of clarity and explanation, each 
media gateway controller is depicted in figure 3 as controlling a single media 
10 gateway whereas, in a practical network, a media gateway controller may well 
control several gateways. 

The gateway address translator 35, which is shown in further detail in figure 4, acts 
as a proxy for all media gateways in a multi-vendor, media gateway control 
15 MEGACO-style, voice over IP or voice over ATM network. The gateway address 
translator provides a proxy function for origination and termination gateways, and a 
substitute for the intermediate gateways. 

There are three elements to the provisioning required to support the gateway 
20 address translator. These are: 

• Provisioning the gateway address translator in place of the physical gateways at 
the media gateway controller, and provisioning the gateway proxies at the 
gateway address translator; 

• Provisioning the physical gateways at the gateway address translator and 
25 associating with the gateway proxies; 

• Provisioning the intermediate virtual gateways and bearer circuits at the gateway 
address translator. 

As depicted in figure 4, the translator incorporates first and second gateway proxies 
30 324, 334 corresponding to the respective gateways 32, 33 (figure 3), and first and 
second virtual gateways 325 and 326, the latter being coupled via a virtual bearer 
circuit 40. The address of each proxy is provisioned at the respective media 
gateway controller in place of that of the respective gateway so that the controller 
believes it is controlling that gateway directly. The address of the media gateway 
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controller does not need to be provisioned at the gateway address translator 
because the translator can extract this information when the media gateway 
controller registers with its gateway. This provides a two-way communication path 
between the gateway proxy of the gateway address translator and the media 
5 gateway controller. If the media gateway controller assumes the same well-known 
port is used by all gateways, a different IP address must be used for each proxy. 
Otherwise, different ports at the same address will be sufficient. 

It will be appreciated that figure 4 is a functional diagram in which the various 
1 0 integers will be constituted by software entities. 

Figure 4a shows the construction of the gateway address translator in further detail. 
Again, it will be appreciated that figure 4a is a logical or functional diagram, as the 
address translator will normally be constituted in software form, e.g. as machine 
15 readable operating instructions on a storage medium. 

An association is also established between the virtual circuits represented by the 
virtual gateway elements. It is through the association of these virtual circuits that 
the gateway address translator is able to relate the two calls (one supervised by the 
20 first vendor's respective media gateway controller, the other supervised by the 
second vendor's respective media gateway controller) which have different call 
identifiers. 

The gateway address translator forwards device control messages between the 
25 gateway address translator and the gateway. The address of the gateway, which 
would ordinarily be provisioned at the respective media gateway controller, is, as 
discussed above, provisioned at the gateway address translator. The gateway 
address translator manipulates device registration messages, substituting the 
address of the gateway proxy in place of that of the respective media gateway 
30 controller, so that the address of the gateway address translator need not be 
provisioned at the gateway. This provides a two-way communication path between 
the gateway proxy of the gateway address translator and the gateway. 
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The gateway address translator receives all media gateway controller (MGC) to 
media gateway (MG) device control commands for all gateways involved in a call, 
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and ensures that all gateways are aware of all the bearer information to connect 
VoIP streams between the gateways to establish a VoIP call. No communication 
between media gateway controllers containing any bearer information is therefore 
required and existing CCS7 messaging and CCS7 networks can be used. 

5 

The gateway address translator receives all device control messages from the 
media gateway controller, and responds to the media gateway controller as if the 
translator were the real gateway involved in the call. In effect, the media gateway 
controller 'thinks', wrongly, that the gateway address translator is in fact the gateway 
10 that it controls. The gateway address translator, through this proxy activity, 
determines what information each gateway should receive in order to properly setup 
the voice over IP communication. 

By using the gateway address translator to proxy media gateway controller (MGC) to 
15 Media Gateway (MG) commands, communication between media gateway 
controllers can thus advantageously use the existing, proven CCS7 network instead 
of the unproven, unimplemented protocols currently being designed for media 
gateway controller to media gateway controller communication. As all vendors 
currently have diverging protocols for media gateway controller to media gateway 
20 controller communication, service providers wishing to provide a multi-vendor VoIP 
or VoATM network with one media gateway controller from vendor A and another 
media gateway controller from vendor B are now enabled to do so. 

The gateway address translator advantageously comprises a software entity that 
25 can run on a separate computer platform, on a router in the IP network, or on the 
same computer platform running one of the media gateway controllers. Each device 
control protocol should provide acknowledgement of IP addresses in device control 
create connection messages. For example, protocols used by Nortel Networks, 
such as ASPEN provide for this - the gateway simply ACKs the SDP, which contains 
30 the IP address to use for the RTP stream. Protocols used by gateways from other 
vendors need to follow a similar convention. 

A call walk-through for the network of figure 3 is illustrated in figure 5. It will of 
course be understood that, for clarity, figure 5 is restricted to the call setup 
35 procedure and does not depict call progress (ACM), answer or release, as these 

9 



latter features will be appreciated by the skilled worker from an understanding of the 
call setup process shown in the figure. 

Figure 6 shows an alternative network arrangement in which one media gateway 
5 controller is constituted by a soft switch 61 supplied by one vendor and controlling a 
respective gateway 62, and the other media gateway controller is constituted by a 
distributed MGC pair (63, 65) providing separate ingress and egress functions and 
supplied by another vendor. As before, the gateway address translator ensures that 
each vendor's products can use their own messaging protocols. 

10 

Figure 7 shows a call walkthrough for the network arrangement of figure 6. Again, in 
the interests of clarity, the diagram has been restricted to the call setup process. 

It will be appreciated that if a media gateway controller assumes the same well- 
15 known port number is used by all gateways, a different IP address must be used for 
each gateway proxy on the gateway address translator. Otherwise, different ports at 
the same address will be sufficient. If a vendor's network management system is 
integrated such that the gateway element manager determines the addresses of the 
gateways from the same provisioning data as the media gateway controller, then the 
20 gateway proxy function of the gateway address translator must also be capable of 
acting as proxy for maintenance messages as well as device control messages. If 
the vendor's network management system is integrated such that gateways must be 
brought in service by an element manager before circuits are available for 
processing by the media gateway controller, rather than assuming they're available 
25 if they succeed on registration, then the virtual gateway must be capable of spoofing 
the minimal service maintenance commands of the element management system 
(SNMP or other 

It will be understood that the above description of a preferred embodiment is given 
30 by way of example only and that various modifications may be made by those skilled 
in the art without departing from the spirit and scope of the invention. 
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